home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Aug 89 / X0111-Re A little NIL Hel-Aug89 < prev    next >
Encoding:
Text File  |  1989-08-29  |  1.6 KB  |  41 lines  |  [TEXT/GEOL]
  1. Item    3816114                         28-Aug-89        19:30
  2.  
  3. From:   SCHMUCKER1                      Schmucker, Kurt,APL
  4.  
  5. To:     SARGENT                         Sargent, Greg,APL
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    Re: A little NIL Help
  10.  
  11. Greg,
  12.  
  13.     MacApp 2.0ß9 checks for many conditions that would sometimes just slide by
  14. before.  Like uninitialized variables.  If a variable is unitialized and you
  15. use its value in a conditional, it might just seem to work because the random
  16. bits that are in that variable might meet the test.  Then, later, when you
  17. least expect it, KABOOM.
  18.  
  19.    Every other MacApp programmer is being caught by the same things that are
  20. now troubling you.  An object failing discipline usually means that you tried
  21. to send a message to something that wasn't an object.  Use the "S" command in
  22. the debugger to see where you were when you blew up, and check to see that
  23. recently allocated objects truly got allocated.  Use FailNil to test
  24. allocations.
  25.  
  26.     The popups are failing because you are doing something that requires the
  27. grafport to be set (in MacApp terms, the view to be focused).  This is often
  28. something like calling one of the coordinate system changing routines
  29. (LocalToQD).  MacApp now has MANY occurances of the "This view should really be
  30. focused now, I wonder if the programmer has done so, let's check it" call --
  31. which is AssumeFocus.  If you get caught by one of these, just look in the 2.0
  32. release notes and check out your uses of the routines which assume focusing.
  33.  
  34.     We've all been there.  And making these changes will make your code more
  35. robust.
  36.  
  37.     Best of luck,
  38.  
  39.         Kurt
  40.  
  41.